OpenEdge Development:<br />Progress 4GL Handbook Other variable qualifiers

You can qualify a variable definition in a number of ways to modify these defaults. To do this, append one of the keywords listed in Table 2–4 to the end of your variable definition.

Table 2–4: Variable qualifiers
Keyword	Followed by
`INITIAL`	The variable’s initial value.
`DECIMALS`	The number of decimal places for a `DECIMAL` variable.
`FORMAT`	The display format of the variable, enclosed in quotation marks.
`LABEL`	The label to display with the variable. (The default is the variable name itself.)
`COLUMN-LABEL`	The label to display with the variable when it is displayed as part of a column of values. (The default is the `LABEL` if there is one, otherwise the variable name.)
`EXTENT`	An integer constant. This qualifier allows you to define a variable that is a one-based array of values. You can then reference the individual array elements in your code by enclosing the array subscript in square brackets, as in myVar[2] = 5.

As an alternative to specifying all of this, you can use the following syntax form to define a variable that is LIKE another variable or database field you’ve previously defined:


DEFINE VARIABLE `varname` LIKE `fieldname`

In this case it inherits the format, label, initial value, and all other attributes of the other variable or field. This is another strength of the Progress 4GL. Your application procedures can inherit many field attributes from the database schema, so that a change to the schema is propagated to all your procedures automatically when they are recompiled. You can also modify those schema defaults in individual procedures.

There’s one more keyword that you should almost always use at the end of your variable definitions, and that is NO-UNDO. This keyword has to do with how Progress manages transactions that update the database. When you define variables in your 4GL programs, Progress places them into two groups. Those that don’t have the NO-UNDO qualifier are treated as though they were a database record with those variables as fields. If any of the variable values are modified during the course of a database transaction, and then the transaction is backed out, changes to the variable values made during the transaction are backed out as well, so that they revert to their values before the transaction started. This can be very useful sometimes, but in practice, most variables do not need this special treatment, and because Progress has to do some extra work to manage them, it is more efficient to get into the habit of appending NO-UNDO to the end of your variable definitions unless the variable is one that should be treated as part of a transaction. This places them into a second group where Progress manages them without the transaction support.